feature(branch_sweep): sweep the rest of the organism from the Brain - #280

Why central rather than 25 copies

Mind and Brain now sweep themselves, but a repo's GITHUB_TOKEN reaches only that repo — so covering the rest of the organism's development repos would mean 25 copies of the same workflow, drifting apart the moment one is edited. PAT_PYAUTOLABS already exists for exactly this kind of cross-repo work, so the sweep is written once here and pointed at each repo in turn.

Targets are derived, never listed

The first version of this PR carried a file listing the repos. CI rejected it, and was right to. The tenant firewall keeps instance facts — satellite repo names, GitHub owners — out of the framework organs so they stay adoptable as a config-diff fork, and a hardcoded list of slugs is exactly that leak.

Worse, it had smuggled it past: the firewall scans only .py and .sh, so a .txt list was not clean, only invisible. A hole to close, not a technique to keep.

The hygiene conductor had already solved this, and said so in the allowlist entry it deleted — "derives its repo sets from the body map, so it names no instance fact at all." Same answer here. bin/branch_sweep_targets.py expresses policy as categories (organ, library, workspace, workspace_test, workspace_developer, howto) and reads which repos fill them from repos.yaml.

Both exclusions now fall out of the categories rather than being named twice:

• The skill's two Never-touched repos live in categories this does not sweep, so no rule has to know them.
• The Mind and the Brain drop out by organ role, not name — each hosts its own branch_sweep.yml, and sweeping them centrally too would put two sweepers on one repo with different credentials. Roles are generic; an adopting fork has a Mind and a Brain whatever it calls them.

The derived set is 25 repos where the hand-list was 18. Not scope creep — the hand-list had quietly omitted repos indistinguishable from ones it included. A principled boundary includes them; the audit-first gate below is what keeps that safe.

The gate is structural, not procedural

• mode=delete refuses to run without an explicit repos list. There is no delete-everything form of this workflow; the all-repos path is audit-only.
• A target the body map does not make sweepable fails the whole run — including a run that also names valid repos. Fail closed, not partially.
• The scheduled run is audit-only regardless of input.

Why stricter here than for Mind/Brain

Those are solo agent repos. The libraries and workspaces take pull requests from outside contributors, and the per-repo skill's protection for that case — "never enumerate origin-only collaborator branches" — cannot hold in a workflow, where every branch it sees is origin-only. A human reading the audit per repo is the substitute, so the mechanism makes that step unskippable rather than trusting a runbook. (Fork PRs are unaffected — their heads live in the fork.)

Checks

pytest tests/ → 507 passed · check_skill_line_counts.sh → OK · repos_sync.py --check in full → all 12 checks green, including the tenant firewall.

That last one is the lesson from the first round: I ran pytest and called it verified, but pytest was never the failing gate — repos_sync.py is a separate CI step I hadn't run locally.

Tests use a synthetic body map throughout. Necessary (this file is .py under an organ, so a fixture naming a real repo would be the same leak), but also better: it pins the contract — categories in, slugs out, unknown category fails closed — rather than today's roster.

The delete gate was exercised directly against the real derived set, 8 cases:

🤖 Generated with Claude Code

https://claude.ai/code/session_01KwqicJpMqmcT5RVbyNwdKq